src/dashboard/Data/Browser/Databrowser.scss (1)

27-90: Consider keyboard/a11y for panel header checkbox

panelHeader is clickable while the nested input[type="checkbox"] is pointer-events: none, and the header div itself is not focusable. That means keyboard users can’t toggle selection easily, and screen readers may expose a checkbox that doesn’t respond to direct interaction. Consider either:

• Making the checkbox itself the interactive control (no pointer-events: none, with proper onChange wiring), or
• Adding tabindex={0} and keyboard handlers (Enter/Space) to the header while treating the checkbox as purely decorative (aria-hidden="true").

This would keep the current UX while improving accessibility.

src/components/Toolbar/Toolbar.react.js (1)

161-188: Add PropTypes for new panel management props

The Add/Remove/Show/Hide panel controls are wired correctly and gated on classwiseCloudFunctions, but the new props (addPanel, removePanel, panelCount, togglePanel, isPanelVisible) aren’t reflected in Toolbar.propTypes. Adding them (with the appropriate function/number/bool types) would make misuse easier to catch.

src/dashboard/Data/Browser/DataBrowser.react.js (4)

80-136: Multi-panel state, persistence, and selection handling – behavior check and cleanup

A few points around the new state/persistence wiring:

1. New localStorage-backed flags default to “on”

   • storedSyncPanelScroll, storedBatchNavigate, and storedShowPanelCheckbox are initialized with getItem(...) !== 'false', so the features are enabled by default even when no key exists yet. Toggling stores 'true' / 'false'.
   • This effectively turns these features on for existing users after upgrade. If that’s intentional, this is fine; if you’d prefer opt-in behavior, consider switching the reads to === 'true' instead.

2. setSelectedObjectId multi-panel batch logic

   • The batch calculation around displayedObjectIds and _objectsToFetch looks sound (selected row anchored at start of batch, pulling up to panelCount objects, using cache when fresh).
   • Near the end of the dataset, panelCount can exceed displayedObjectIds.length (e.g. adding a panel when there aren’t enough remaining rows). That’s harmless but means batchNavigate and prefetch will step by panelCount even though fewer panels are actually rendered. If you want UI and behavior to stay in lockstep, you could clamp the effective step size to displayedObjectIds.length.

3. Minor style cleanup from static analysis

   • Inside setSelectedObjectId, newMultiPanelData is never reassigned, only mutated, so it can be a const:

•      let newMultiPanelData = { ...prevState.multiPanelData };
  

•      const newMultiPanelData = { ...prevState.multiPanelData };
  

Overall the selection and state wiring look correct; the above are mainly behavioral choices and small polish items.

Also applies to: 159-171, 776-848, 886-908

---

229-245: Scroll synchronization: avoid potential scroll churn and clarify scroll target

The scroll-sync plumbing generally works, but there are a couple of edge cases to consider:

1. Possible scroll event ping-pong between panels

   • handlePanelScroll copies event.target.scrollTop to all other panelColumnRefs. Those programmatic updates will in turn fire onScroll on the other columns, which then write back to the origin column. Most browsers suppress redundant events when the value is unchanged, but this isn’t guaranteed and can cause extra scroll events.
   • You can guard against this cheaply by only writing when the delta is non-zero, e.g.:

   const scrollTop = event.target.scrollTop;
   this.panelColumnRefs.forEach((ref, i) => {
     if (i !== index && ref?.current && ref.current.scrollTop !== scrollTop) {
       ref.current.scrollTop = scrollTop;
     }
   });

2. Nested scrolling vs. “Scroll to top” behavior

   • The container aggregationPanelRef still has overflow: auto, while each .panelColumn also has overflow-y: auto. In multi-panel mode, most of the vertical scrolling will happen inside columns, but the “Scroll to top” setting only resets this.aggregationPanelRef.current.scrollTop. Users can end up with columns scrolled independently even after an auto-reset.
   • If you want “Scroll to top” to fully reset multi-panel layout, consider also resetting each panelColumnRef.current.scrollTop when that flag is enabled.

The current implementation is functional; these changes would make scroll behavior more predictable and robust.

Also applies to: 297-324, 910-939

---

941-990: Reduce duplicate Cloud function calls between multi-panel fetch and prefetch

fetchDataForMultiPanel and prefetchObject both call Parse.Cloud.run with the same cloudCodeFunction and object pointer, but via different paths:

• setSelectedObjectId collects _objectsToFetch and calls fetchDataForMultiPanel for each (current batch).
• handlePrefetch detects a navigation pattern and calls prefetchObject for upcoming objects (future batches).

Because handlePrefetch() is invoked at the end of setSelectedObjectId’s callback, you can end up with both functions firing separate network requests for the same object (especially in multi-panel mode where upcoming batch rows overlap with displayedObjectIds).

To avoid redundant Cloud calls and reduce load:

• Consider having fetchDataForMultiPanel(objectId) delegate to prefetchObject(objectId) and only augment multiPanelData from the existing prefetchCache, or
• Extract a shared “fetch once and update both caches” helper that both prefetchObject and fetchDataForMultiPanel use.

That would ensure each object’s panel data is fetched at most once per staleness window while keeping the current caching and media-prefetch behavior.

Also applies to: 1095-1127, 1231-1257

---

1414-1486: Multi-panel rendering: loading UX and selection/checkbox accessibility

The multi-panel rendering block is a nice composition, but there are a few UX/a11y details worth tightening:

1. Loading state for secondary panels

   • Panels for displayedObjectIds other than the currently selected row derive panelData from multiPanelData[objectId] || {} and use isLoading = objectId === selectedObjectId && isLoadingCloudFunction.
   • When fetchDataForMultiPanel is fetching data for non-selected objects, those panels render with empty data and showAggregatedData={true}, which leads AggregationPanel to show “No object selected.” rather than a loading indicator.
   • If you want to signal that data is on the way, consider tracking a per-object loading flag (or checking presence in _objectsToFetch) and passing isLoadingCloudFunction accordingly so secondary panels show a spinner instead of “No object selected.” while fetching.

2. Panel header checkbox interaction

   • The header div has onClick toggling selectRow(objectId, !isRowSelected), while the nested <input type="checkbox"> is readOnly and rendered purely as a visual indicator. Combined with pointer-events: none in the SCSS, the checkbox isn’t directly interactive, and the header div isn’t keyboard-focusable.
   • For better accessibility, consider:
     • Making the checkbox itself the interactive element (handling onChange and letting it focus), or
     • Treating the checkbox as decorative (aria-hidden) and adding tabIndex={0} + key handlers on the header so keyboard users can toggle selection.

3. Scroll-to-top vs multi-panel columns

   • As noted earlier, the “Scroll to top” behavior still only touches aggregationPanelRef.scrollTop. If you decide that setting should also reset per-panel scrolls, this render block is the right place to apply those resets via the panelColumnRefs.

Behavior is otherwise coherent: the correct error state is only passed to the currently selected object, and separators are rendered cleanly between panels.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: mtrezza
Repo: parse-community/parse-dashboard PR: 2957
File: src/dashboard/Data/Browser/BrowserTable.react.js:584-597
Timestamp: 2025-07-31T06:12:17.707Z
Learning: In Parse Dashboard's data browser selection logic (src/dashboard/Data/Browser/BrowserTable.react.js), the `selection['*']` pattern is used to handle global operations that pass `{ '*': true }` to indicate all items are selected, particularly for bulk operations like delete. This is not dead code but serves as compatibility layer for global operations that don't go through normal individual row selection workflows.

Learnt from: mtrezza
Repo: parse-community/parse-dashboard PR: 2828
File: src/dashboard/Data/Browser/Browser.react.js:1605-1607
Timestamp: 2025-05-27T12:09:47.644Z
Learning: In script execution dialogs in Parse Dashboard (specifically the `confirmExecuteScriptRows` method in `src/dashboard/Data/Browser/Browser.react.js`), individual `setState` calls to update `processedScripts` counter should be kept as-is rather than batched, because this provides real-time progress feedback to users in the dialog UI.

src/components/Toolbar/Toolbar.react.js (1)

161-189: Panel controls wiring looks solid; consider UX tweak for Add Panel

The visibility and enablement logic for Add/Remove/Show/Hide is consistent with panelCount and isPanelVisible, and matches the DataBrowser API. Only minor UX nit: addPanel is callable even when no row is selected, in which case it silently does nothing. If that’s a common case, consider disabling Add Panel (or showing a tooltip) until a row is selected so the behavior is more obvious.

src/dashboard/Data/Browser/DataBrowser.react.js (5)

789-848: Multi-panel batch selection and deferred fetch pipeline is well-structured

The extended setSelectedObjectId logic correctly:

• Tracks selection history for prefetch heuristics.
• Recomputes displayedObjectIds only when a new object falls outside the current multi-panel batch.
• Reuses cached data where available and stages missing objects for later async fetch via _objectsToFetch.

Using a functional setState plus a post-update callback avoids race conditions. If you want to reduce state churn later, _objectsToFetch could be moved to an instance field, but that’s an optional micro-optimization.

---

886-908: Sync scroll and batch toggles behave correctly; scroll sync implementation is reasonable

The three toggle helpers correctly flip state and persist to localStorage, aligning with the default-on pattern used at initialization. Scroll syncing (handlePanelScroll and handleWrapperWheel) is straightforward and should work well in practice; any redundant scroll events will quickly converge without affecting correctness.

Also applies to: 910-939

---

941-990: Per-object multi-panel fetch is correct; consider DRY’ing with prefetchObject

fetchDataForMultiPanel correctly honors prefetch staleness, reuses cached entries, and updates both prefetchCache and multiPanelData on fresh fetches. It duplicates some logic from prefetchObject, so if this grows further it might be worth centralizing the Parse.Cloud.run + cache update logic in a shared helper.

---

992-1055: Panel add/remove logic is sound; only minor polish possible

addPanel correctly builds a contiguous batch starting at the selected row, hydrates multiPanelData from the live panel or cache, and defers missing fetches. removePanel cleanly decrements panelCount and trims displayedObjectIds.

Minor notes (optional):

• When currentIndex is -1 (no valid selection), addPanel is a silent no-op; pairing this with a disabled Add Panel button or tooltip would make the UX clearer.
• In removePanel, returning null instead of {} in the panelCount <= 1 case would avoid an unnecessary re-render.

---

1414-1486: Multi-panel rendering path is coherent and matches the data model

The multi-panel branch correctly:

• Uses displayedObjectIds and multiPanelData to drive per-panel content.
• Applies per-column scroll refs and onScroll handlers for sync behavior.
• Integrates optional selection checkboxes and reuses the existing AggregationPanel API.

The single-panel fallback remains unchanged, so the feature is additive and backward-compatible. If in the future you need per-panel error reporting, you may want to model errorAggregatedData by objectId, but the current shared handling is acceptable.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro